vmh: limit additional buffers to non-Linux configurations#10709
vmh: limit additional buffers to non-Linux configurations#10709kv2019i merged 1 commit intothesofproject:mainfrom
Conversation
Commit 7f66827 ("zephyr: alloc: add 32K virtual heap bucket") unconditionally added 256k to Virtual Heap buckets. Make this conditional on a Kconfig option. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
lyakh
requested review from
abonislawski,
dabekjakub,
dbaluta,
iuliana-prodan,
kv2019i,
lbetlej,
lgirdwood,
mmaka1 and
plbossart
as code owners
There was a problem hiding this comment.
Pull request overview
This PR makes the extra 32KB virtual heap bucket (and corresponding virtual heap region size) configurable so Linux builds can reclaim that memory for virtual page/region bookkeeping.
Changes:
- Add a
VIRTUAL_HEAP_EXTENDEDKconfig option (defaulty) to control whether the additional VMH buffers are included. - Conditionally include the 32KB VMH bucket in
zephyr/lib/alloc.cwhenVIRTUAL_HEAP_EXTENDED=y. - Disable
VIRTUAL_HEAP_EXTENDEDin the Linux overlay, which also reduces the defaultSOF_ZEPHYR_VIRTUAL_HEAP_REGION_SIZEaccordingly.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
zephyr/lib/alloc.c |
Wraps the 32KB VMH bucket behind CONFIG_VIRTUAL_HEAP_EXTENDED. |
zephyr/Kconfig |
Introduces VIRTUAL_HEAP_EXTENDED and makes virtual heap region size default conditional. |
app/os_linux_overlay.conf |
Disables VIRTUAL_HEAP_EXTENDED for Linux builds to free VM space for virtual regions/pages. |
|
Is this solution intended for the gradual shrinkage of the WHM region as we transition towards vregions? I.e. are you going to put more buffers under the Kconfig option/ifdef in the future? |
Yeah, we need to have incremental changes here via Kconfig so we can transition safely, fwiw we also have to coalesce our L1/L2 page tables as they are spread out in virtual space making larger continuous virtual buffer allocations more problematic (see purple boxes in map). |
|
@lgirdwood Thanks for clarification. Just one minor suggestion: If we expect a really longer transition period, I would reverse the logic Kconfig and call it "Limit the Virtual Heap" instead of "Extend ..." just to emphasize that the VMH is being shrunk. |
Ack - sounds good to me. |
@wjablon1 please check the PR description. The main purpose of this PR is to limit the effects of another recent PR. So it isn't reducing the scope of VMH, but returning it to a slightly earlier state. However, if we want to keep this Kconfig and re-use it in the future to further shrink VMH, sure, we can rename it. |
|
I thought we would simply shrink VMH along with moving allocations, which was supposed to happen shortly but its again 0x100000? |
@abonislawski #10702 switches some allocations to vregion but I'd rather not add yet another commit to it but restore the state with which it was developed and tested before merging it |
Commit 7f66827 ("zephyr: alloc: add 32K virtual heap bucket") unconditionally added 256k to Virtual Heap buckets. Make this conditional on a Kconfig option.